The present invention relates generally to mobile radio systems.
FIG. 1 outlines the architecture of mobile radio systems. As a general rule, a mobile radio system essentially comprises:                a radio access network (RAN) 1 comprising base stations 2 and base station controllers 3, and        a core network (CN) 4.        
The radio access network 1 is connected to mobile stations 5 via an interface 6 which is called the radio interface and to the core network via an interface 7. Within the radio access network, the base stations communicate with the base station controllers via an interface 8.
The core network 4 is connected both to the radio access network via the interface 7 and to external networks, not specifically shown.
In these systems, technological changes are making it necessary to draw a distinction between second generation (2G) technologies, in particular Global System for Mobile communication (GSM) technologies, and third generation (3G) technologies, in particular Universal Mobile Telecommunication System (UMTS) technologies.
In the GSM, the radio access network is called the Base Station Subsystem (BSS), a base station is called a Base Transceiver Station (BTS), and the core network is called the Network Sub-System (NSS). The NSS essentially contains entities (network nodes) such as the Mobile-services Switching Center (MSC). The radio interface is called the Um interface, the interface 7 is called the A interface, and the interface 8 is called the Abis interface.
As a general rule, these systems are covered by standards, and for more information reference may be had to the corresponding standards published by the corresponding standards organizations.
The GSM standards have evolved recently with the introduction of the General Packet Radio Service (GPRS) offering services in packet-switched mode and then the Enhanced Data rates for GSM Evolution (EDGE) offering higher bit rates at the radio interface and divided into two improvements: the first, known as Enhanced Circuit Switched Data (ECSD), increases the bit rates in circuit-switched mode and the second, known as Enhanced GPRS (EGPRS), increases the bit rates in packet-switched mode.
In the GPRS and EGPRS, the interface 7 is called the Gb interface and the core network essentially contains entities (network nodes) such as Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) entities, the latter in turn communicating with packet-switched mode external networks, in particular Internet Protocol (IP) networks.
A radio access network using the GSM/EDGE radio access technologies is called a GSM/EDGE Radio Access Network (GERAN).
In the UMTS, the radio access network is called the UMTS Terrestrial Radio Access Network (UTRAN), a base station is called a Node B, a base station controller is called a Radio Network Controller (RNC), and a mobile station is called a User Equipment (UE). The radio interface is called the Uu interface, the interface 7 is called the lu interface, the interface 8 is called the lub interface, and an interface between RNC is introduced, and is called the lur interface. The lu interface is itself made up of two interfaces, of which one is called the lu-cs interface (where “cs” denotes “circuit-switched”) and the other is called the lu-ps interface (where “ps” denotes “packet-switched”).
In the UMTS, the core network essentially contains 3G-MSC, 3G-SGSN, and 3G-GGSN entities (network nodes) (the MSC, SGSN, and GGSN entities of the 2G systems previously mentioned are respectively called the 2G-MSC, the 2G-SGSN, and the 2G-GGSN entities). The lu-cs interface connects the UTRAN to the 3G-MSC and the lu-ps interface connects the UTRAN to the 3G-SGSN.
The UMTS access network differs from the GSM, GPRS and EDGE access network essentially because of the introduction of higher performance radio access technologies, based in particular on using the Wideband-Code Division Multiple Access (W-CDMA) technique. The core network of the UMTS offers multimedia services at high bit rates.
As a general rule, the UMTS is also covered by standards, and for more information reference may be had to the corresponding standards, published by the corresponding standards organizations.
A GSM general packet radio service as described above operates in a mode called the A/Gb mode.
With the aim of harmonizing the services offered via the UMTS and the GSM/EDGE radio access technologies, a new mode of connecting a GERAN directly to 3G-MSC or 3G-SGSN core network nodes has been introduced, and is called the lu mode.
In the lu mode, real time services will initially be offered via the lu-cs interface, which connects a GERAN to a 3G-MSC. In this initial stage, the lu-ps interface, which connects a GERAN to a 3G-SGSN, will provide only non-real-time services. Subsequently, real-time services will also be supported at the lu-ps interface.
A new network core interface has therefore been defined, so that real-time services and non-real-time services can be offered by a packet-oriented interface such as the lu-ps interface. One such architecture is the IP Multimedia Sub-System (IM SS) architecture. Multimedia services can then be offered via a single reference point with signaling relating to call session control transported via a Session Initiation Protocol (SIP).
Signaling relating to multimedia call session control has until now been defined for UMTS technologies. Thus the signaling typically includes setting up an RRC connection between a mobile station and an RAN, followed by setting up a UMTS bearer to transport the signaling relating to the SIP protocol. The Radio Resource Control (RRC) protocol is defined in the 3G TS 25.33 standard. The SIP and the associated Session Description Protocol (SDP) are defined by the Internet Engineering Task Force (IETF), which is the Internet Protocol (IP) standards organization.
FIG. 2 shows the main steps of this kind of signaling. For simplicity, FIG. 2 shows only one of three segments into which call session control is divided, in this instance the segment from the calling UE to its S-CSCF (Serving-Call Session Control Function); the other two segments are the segment from the called UE to its S-CSCF and the segment which connects the S-CSCF of the calling UE and the called UE. The S-CSCF and Proxy-Call Session Control Function (P-CSCF) entities are core network entities responsible for multimedia call session control.
Note that throughout the description the term UE is used by way of example, and it must be understood that it can refer to any mobile station (UMTS and/or GERAN).
Step S1 is essentially a preliminary step preceding session set-up.
Step S1 uses a packet-switched mode data protocol (Packet Data Protocol (PDP)) context activation procedure, which is necessary for transporting multimedia session control signaling. A PDP context includes a set of UMTS bearer parameters, including Quality of Service (QoS) parameters, etc. This step is followed by another PDP context activation procedure, necessary for transporting data associated with the multimedia session itself. Because these two PDP contexts concern the same IP address, step S1 is called the primary PDP context activation procedure.
Step S1 essentially comprises the following steps. In a step S1, a PDP context activation request is sent from the UE to the RAN, with the corresponding end-to-end QoS quality parameters for the SIP level signaling UMTS bearer. In a step S12, the 3G-SGSN commands the setting up of a Radio Access Bearer (RAB) so that a medium complying with the applicable quality of service constraints is available between the UE and the 3G-SGSN. When the RAN receives this kind of request, after call admission control, it sets up a Radio Bearer (RB) at the radio interface (step S13) and an lu bearer at the lu interface. RAB set-up can then be confirmed (step S14) and the PDP context activated (S15), after negotiation with the 3G-GGSN (steps S16, S17).
Step S2 essentially sets up the multimedia session at the SIP level. This step includes negotiation to determine the characteristics for the session being set up. The negotiation includes negotiation of codecs, for the purpose of determining, for the session concerned, a list or set of codecs which can be supported in common by the two parties to a call and authorized for all the intermediate network nodes.
The codecs determine, both in the mobile stations and in the radio access network (in particular in the base stations) and in the core network, how to perform the necessary source coding and channel coding, in particular for transmission at the radio interface. For example, in the GSM, there are different types of codecs for speech coding: Full Rate (FR), Enhanced Full Rate (EFR), Half Rate (HR), and Adaptive Multi-Rate (AMR) codecs, the latter being particularly beneficial in that AMR coding optimizes the quality of service (in this instance by selecting an instantaneous optimum combination of a given source code and a given channel code, as a function of the transmission conditions encountered). There are two types of AMR codecs: narrowband AMR codecs, and wideband AMR codecs. A wideband AMR codec offers a better quality of service but necessitates higher radio bit rates. Speech is, of course, merely one example of the different components or media streams forming a multimedia session.
Step S2 is not shown in detail in FIG. 2, but more information can be obtained by referring to the 3G TS 23.228 standard. Step S2 essentially comprises the following steps. Once an RB has been set up for SIP signaling (in the preceding step S1), a first task is for the SIP client to discover its P-CSCF. It must then declare itself and register with its S-CSCF, which will call on other entities of the core network. Finally, at the time of session set-up, a “SIP Invite” request is sent to the called party via the P-CSCF and S-CSCF entities. This message contains an SDP Datagram which indicates, for each media stream, that the calling UE wishes to set a number of media parameters, such as: media type, QoS attribute combination, list of codecs that can be supported for this session, etc. The P-CSCF and S-CSCF entities associated with the calling party and then with the called party then perform a service check on these parameters (against criteria specific to the network). The called party then determines, amongst other things, its own list of codecs that can be supported for the session, and then a list of codecs than can be supported in common by the two parties (calling party and called party), and then returns the latter list to the calling party. The calling party then determines which media streams must be used for the session and which codecs in the list must be used for the session.
Step S3 is essentially an end of session set-up step and includes a resource allocation step based on media stream characteristics determined in step S2 (QoS attributes, negotiated codecs, etc.).
Step S3 also uses a PDP context activation procedure, which is called a secondary PDP context activation procedure to distinguish it from the primary context activation procedure of step S1. Step S3 is similar to step S1, except that the parameters for the UMTS bearer to be set up now correspond to the requirements determined in S2. Step S3 itself includes steps similar to those of step S1, and which are not described again for this reason.
Step S3 thus includes the setting up of an RAB for the secondary PDP context. When the RAB has been set up, the RAN performs an admission check and accepts or rejects the call.
In the case of the UTRAN, the RAB request must be accepted because all types of codecs (modes) must be supported by the Node B, or more generally by the RNS that contains the Node B (the RNS being a sub-network within the UTRAN, formed of an RNC and one or more Node B controlled by that RNC). The only situation in which this kind of request would be rejected is one of congestion (in which case no resource is available).
In the case of the GERAN in particular, a problem arises because not all BTS can support all types of codecs. For example, in the case of media streams consisting of speech, not all BTS can support Wideband AMR codecs. Thus if two SIP clients are negotiating a codec for a given media stream, but that codec is not supported by the BTS (or more generally by the BSS that contains the BTS), activation of the PDP protocol context will fail. This will necessitate SIP re-negotiation, which delays the setting up of the call, which can be unacceptable.
One solution would be to interchange the SIP negotiation and secondary PDP protocol context activation procedures. However, this solution cannot be used because it is not compatible with the standard.